Applying Data Distribution Management and Ownership Management Services of the HLA Interface Specification

The HLA Interface Specification defines services for Data Distribution Management (DDM) and Ownership Management (OM). In addition to Declaration Management, DDM is introduced to provide value based filtering on the attribute values to be communicated. The main objectives of DDM are reduction of the data to be processed by the receiving federate (scalability) and reduction of the data actually sent over the network (performance). However, applying DDM leads to an increase in computational effort by the RTI, especially when many regions need to be updated regularly. To determine the conditions, under which DDM is of benefit, a predator-prey federation has been designed and implemented. The effects of applying several strategies using DDM and OM were analyzed and experiments were conducted using the available DMSO RTI. The usage of DDM and OM is evaluated and guidelines for future use of these services are presented. (publication). Also the object classes, attributes and interactions it needs to perform its task are registered (subscription). Through the Data Distribution Management (DDM) services, a federate can also subscribe to (ranges of ) attribute values. The aim is to filter as much information as possible at the source. The responsibility to update certain attributes of objects, called attribute ownership, can be transferred between federates through the Ownership Management (OM) services. This paper describes and evaluates the Data Distribution Management and Ownership Management services. A distributed simulation model is constructed to measure the performance of the currently available DMSO RTI and to evaluate design trade-offs involving the use of these two management services. The paper is organized as follows. Section 2 focuses on the Data Distribution Management (DDM) services and Section 3 on the Ownership Management (OM) services. Section 4 describes a simulation model, which is the basis of a case study to test several strategies for using the DDM and OM services. Based on the currently available DMSO RTI, this federation has actually been implemented. Section 5 gives an overview of the design and implementation of the federation. Experiments investigating performance issues are described, and their initial results are presented in Section 6. Finally, Section 7 presents an evaluation and some guidelines for future use of the DDM and OM services. 2. Data Distribution Management Through the Data Distribution Management (DDM) services, filtering is provided on the actual values of the attributes to be communicated [3]. The main objectives for using DDM are the need for reduction of the data to be processed by the receiving federate (scalability) and reduction of the data actually sent over the network (performance). The fundamental DDM-constructs are routing spaces and regions. A routing space is a Cartesian product of finite intervals (referred to as dimensions), whereas a region is a subspace of a routing space [4]. Federates either express an interest in receiving certain data or declare their intention to send data by defining subscription regions and update regions. The purpose of the regions is to express the scope of interest. The receiving federate can express a scope of interest for receiving data by declaring a subscription region and associating it with attributes of a certain object. A sending federate can express the scope of intention for sending (published) data by declaring an update region and associating it with an attribute. Multiple update and subscription regions can be declared for a single routing space. Communication is established by the RTI only when publish and subscription regions overlap. Due to the dynamic behavior of objects, the scope of interest may change, and thus the regions as well. Since the update– subscription region comparison is done by the sending federates, all federates need to be aware of all subscription regions. Modifying a subscription region will therefore lead to communication overhead caused by region change notifications between federates, and thus increase the network load. Expanding regions In principle it is desired to choose the regions small: federates only receive the information they need and communication overhead is limited. However, when objects move through the simulation space, regions may have to be updated regularly causing region change notifications. A trade-off can be made when determining the region sizes. By expanding the regions with a comfort zone, region boundaries can be updated less frequently. The challenge is to find an efficient balance. The optimal region sizes can be determined in two ways: by analyzing the behavior of objects or by conducting experiments trying different region sizes. Analyzing an object’s behavior mainly involves analyzing the movement through the routing space. Not only the characteristics of velocity and acceleration need to be investigated, but also characteristics such as whether the object stays relatively long in one area before moving to another area. Besides movements, also the interaction ranges and update rates need to be investigated. Regions should at least cover the interaction range. Less frequent update rates of other objects should be taken into account: objects moving fast through the simulation space should still be detected if they move through a certain region in between two state updates. The HLA Interfaces Specification provides a scope advisory mechanism to cope with this problem. If this mechanism is not used, the regions should be expanded such that objects are detected before they move into the actual interaction range. The size of the scope margin depends on the behavior of objects to be detected: objects going in or out of the interaction range should be detected at least once in the scope margin. Besides analyzing the behavior of objects, the characteristics of the entire federation should be investigated, especially to determine whether the use of DDM is of benefit at all. DDM can only be applied efficiently if regions do not overlap too much, because this would result in a poor filter, while causing a large computational overhead due to region comparisons. Region clustering Federation executions with a large number of regions may suffer from overhead caused by region change notifications. Therefore, it may be desirable to reduce the actual number of regions by merging multiple regions into a new region. By associating the attributes of multiple objects with the same region, one region may replace a cluster of regions. The bounding box of the regions to be replaced can define such a cluster. There are a few requirements for applying this strategy. First, the regions to be clustered all have to be defined by the same federate (locality) and must belong to the same class (update or subscribe). Secondly, the clustered regions must behave such that they will overlap or stay relatively close within their routing space for a longer period of time to prevent the cluster from growing large during the course of the simulation. Clustering can be applied either statically or dynamically. In the static approach, the federation designer determines the clusters by analyzing the behavior of all objects and their regions. In the dynamic approach the clusters are adapted during the federation execution to maintain the most efficient clusters. As with regions, clusters should be kept small and changes of clusters should not occur too often to avoid unnecessary data exchange and update notifications. DDM efficiency For each attribute the federation designer must specify whether communication is reliable or unreliable. Unreliable broadcast and multicast communication can be implemented very efficiently, whereas reliable communication involves more overhead. Here we assume that reliable communication is used. The efficiency of applying DDM consists of two parts: the efficiency of the filtering mechanism and the computational overhead. The filtering efficiency can be expressed by comparing the amount of useful data exchanges compared to the total amount of data exchanges (including region change notifications). Expanding regions and region clustering may lead to a less efficient use of regions. On the other hand, the computational overhead may be reduced as this is related to the amount of region change notifications. To investigate the effects of region expansion and region clustering, and to evaluate whether DDM is of benefit at all, a federation could be developed which fulfils the following requirements: objects have a bounded interaction range and move through the simulation space (region expansion); and objects tend to ‘flock’ when they are in each other’s interaction range (region clustering). A federation fulfilling these requirements will be introduced in Section 4. 3. Ownership Management The Ownership Management services provide a facility to transfer attribute ownership and to keep the administration of the update responsibilities up-to-date. Attribute ownership transfer is provided through the push and the pull mechanism. A federate may try to release (push) responsibility for one or more published attributes of an object, or try to acquire (pull) responsibility for one or more attributes of an object (see Figure 1). Ownership transfer between federates will only succeed if both sides agree. However, it is possible to push an attribute unconditionally (nonnegotiated) which may result in an attribute not being updated by any federate until some federate pulls the ownership. The federation designer should define proper ownership migration strategies in order to prevent ownership handover failures and attributes migrating continuously. Figure 1a: The negotiated push mechanism. Figure 1b: The negotiated pull mechanism. Migrating objects Both the push and pull mechanisms operate on attributes only. In case several attributes or even entire objects have to be migrated, problems may arise. Multiple federates may react with a pull attempt on one RTI intention to relinquish ownership owning federate other federate(s) positive answer (relinquish ownership) intention to relinquish ownership request for ownership (pull) positive answer (obtain ownership)